Skip to content

[litmus] Introduce ExS, EIS and EOS variants#1716

Open
diaolo01 wants to merge 1 commit intoherd:masterfrom
diaolo01:exs-fix
Open

[litmus] Introduce ExS, EIS and EOS variants#1716
diaolo01 wants to merge 1 commit intoherd:masterfrom
diaolo01:exs-fix

Conversation

@diaolo01
Copy link
Copy Markdown
Contributor

This PR enables litmus to run tests with -variant exs, eos, eis. This mirrors the ability that herd has to run tests in catalogue/tests/aarch64-faults/.

@murzinv
Copy link
Copy Markdown
Collaborator

murzinv commented Feb 16, 2026

Don't you need to update SCTLR_EL1 to reflect introduced variant(s)?

@diaolo01
Copy link
Copy Markdown
Contributor Author

@murzinv Do you mean litmus should explicitly set those bits when the variants are used? I introduced a check whether the bits are already enabled, otherwise throw an error.

@murzinv
Copy link
Copy Markdown
Collaborator

murzinv commented Feb 16, 2026

@murzinv Do you mean litmus should explicitly set those bits when the variants are used? I introduced a check whether the bits are already enabled, otherwise throw an error.

Well, in current form litmus would just accept new variants, but they have no effect. IIUC, these variants corresponds to FEAT_ExS and allow to control aspects of contexts synchronization. Thus absence of any setting in litmus7 when these variants are present look odd. I do not know what are defaults for those bits in SCTLR_EL1 (architecture says the are RES1) so I'd assume litmus7 should toggle/clear them. Also it'd be handy if there is check for FEAT_ExS so user would be aware if toggling those bits make sense in the first place.

@diaolo01 diaolo01 force-pushed the exs-fix branch 2 times, most recently from b4b00b6 to f2dcbf1 Compare February 19, 2026 13:57
@diaolo01
Copy link
Copy Markdown
Contributor Author

diaolo01 commented Feb 19, 2026

I tested this on hardware using the following test

AArch64 SVC-ifetch.exs1eis0
variant=self,exs
CacheType=DIC
{
  0:X0=instr:"NOP"; 0:X1=P0:L2;
}
 P0          | P0.F       ;
 STR W0,[X1] | ERET       ;
 DSB ISH     |;
 SVC #0      |;
L2:          |;
 B L1        |;
 MOV W9,#1   |;
L1:          |;

exists(0:X9=0)

I get the following result:

Test SVC-ifetch.exs1eis0 Allowed
Histogram (2 states)
39999 *>0:X9=0;
1     :>0:X9=1;
Ok

Witnesses
Positive: 39999, Negative: 1
Condition exists (0:X9=0) is validated
Hash=30df2009caaef631aff2dc9d9ac6a587
variant=self,exs
CacheType=DIC
Observation SVC-ifetch.exs1eis0 Sometimes 39999 1
Topology 39999 :> part=0 [[0]]
Time SVC-ifetch.exs1eis0 0.01

I opted for if variant eis then the relaxation provided by SCTLR_EL1.EIS=0 is in place. I find this a bit mind boggling, let me know if you can think of a better solution. Given this, my understanding is that without variant eis it should be guaranteed that X9=1. Since the SVC is a context synchronising event, should that not guarantee that P0:L2 is populated with a NOP? Am I missing something?

@murzinv
Copy link
Copy Markdown
Collaborator

murzinv commented Feb 20, 2026

I just glaceed over herd side of things and it seems that it is done with assumption that SCTLR_EL1.{EIS,EOS}={0,0} as default. My impression is that default SCTLR_EL1.{EIS,EOS}={1,1} provides stronger guaranties, I think that inverted polarity is the reason of

mind boggling

Obviously, herd and litmus need to be aligned.

Copy link
Copy Markdown
Collaborator

@murzinv murzinv left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code wise everything LGTM. Thanks!

if Cfg.variant Variant_litmus.ConstPacField then
O.fi "if (!check_const_pac_field_variant(%S)) return 0;" doc.Name.name;
if Cfg.is_kvm && Cfg.variant Variant_litmus.ExS then
O.fi "if (!check_exs(%S)) return 0;" doc.Name.name ;
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

perhaps you could also move the eis and eos handling here as well?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have followed the split between check for feature and use feature as it's done for PAC. MTE does the check for feature within the mte_init function, which is in the same location in the code as eis/eos handling.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

MTE does the check for feature within the mte_init function, which is in the same location in the code as eis/eos handling.

Unrelated to the PR. Perhaps MTE would benefit from the similar check/use split...

@diaolo01 diaolo01 force-pushed the exs-fix branch 2 times, most recently from c78e04c to 4ffd2a3 Compare February 23, 2026 16:20
if Cfg.variant Variant_litmus.ConstPacField then
O.fi "if (!check_const_pac_field_variant(%S)) return 0;" doc.Name.name;
if Cfg.is_kvm && Cfg.variant Variant_litmus.ExS then
O.fi "if (!check_exs(%S)) return 0;" doc.Name.name ;
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

MTE does the check for feature within the mte_init function, which is in the same location in the code as eis/eos handling.

Unrelated to the PR. Perhaps MTE would benefit from the similar check/use split...

Copy link
Copy Markdown
Member

@relokin relokin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some minor nits, otherwise this PR looks good to me.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants